Date: Wed, 20 Apr 94 04:30:13 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #123 

To: Ham-Digital 


Ham-Digital Digest Wed, 20 Apr 94 Volume 94 : Issue 123 


Today's Topics: 
*xxBYTE Magazinexx features DSP, May 1994 
Internet <-> packet gateway? 
Internet > Packet gateways?? 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 19 Apr 1994 14:38:24 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews! 
kimbark! khopper@network.ucsd.edu 

Subject: *x*xBYTE Magazinexx features DSP, May 1994 

To: ham-digital@ucsd.edu 


There are two excellent articles about DSP in the new May 1994 
issue of BYTE Magazine. 


The first on pp22,23 carries the title "The Engines to Make Mul- 
timedia Mainstream". This two pager covers the Microsoft DSP API 
and a nice half-page on the TI TMS 320C80. The article has a pie 
chart that indicates a trememdous growth (728$mill to 2,493$Mil) 
in DSP sales from 1993 to 1997. 


The second article is on pp 81-86 and has the title "Desktop Data 
Conferencing". There is an excellent chart showing various pic- 
ture formats and the corresponding required bandwidth for un- 


compressed and compressed transmission. DSP is highlighted as the 
solution to bringing Teleconferencing to our bandwidith limited 
telecommunication channels. Page 84 has a 2/3 page special inset 
on "DSP's and the PC Mainstream" that clarifies the DSP API and 
the AT&T VCOS, IBM MWAVE, and SPOX. The various "DSP Operating 
Systems" are displayed in a brief figure on the same page. Page 
86 has a table depicting 15 different alforithms 
(CLEP...G.711...V.32...) and their bit stream speeds and DSP re- 
quirements. 


Good articles with more than introductory information. 


Ken Hopper, | aa | 
November 9 Vivid Video loo \_j/ool 
HF - CW,PacTOR,RTTY,SSTV loo @ ool 


khopper@midway.uchicago.edu | 


Date: Tue, 19 Apr 1994 15:39:13 GMT 

From: ihnp4.ucsd.edu! pacbell.com! tandem! news@network.ucsd.edu 
Subject: Internet <-> packet gateway? 

To: ham-digital@ucsd.edu 


In article cjt@transfer.stratus.com, ansaldo@fstop.hw.stratus.com (Robert Ansaldo) 
writes: 

>I seem to remember seeing something here about an internet connected machine 
>that will forward email via packet radio. I tried looking back, but the 
>article(s) must have expired. 


N6QMY/BBS Internet Gateway Operating Instructions 
April 11, 1993 


LOCAL USERS: 

Local users are those that log into the bbs via the bbs's telephone modem 
port (510-795-xxxx) or via one of the 4 tnc ports (145.09, 145.79, 223.62, 
or 441.50). Each local user has a bbs account that is used to customize 
how the bbs interacts with the user. 


Local users can set their account up so that all incoming mail addressed 
to their call will be forwarded via a gateway to internet and on to 
other networks (mcimail, compuserve, etc). All the user needs to do is 
enter his email address and turn the feature on. 


EMAIL bob@hal.com 


EMAIL ON 


When the EMAIL feature is turned on the packet message will be deleted 
at the time of forwarding through the gateway. So care should be taken 
that the paths are correct prior to turning the feature on, for instance 
enable it, send a test message, and disable it. After a successful 
transfer re-enable the feature. To disable the auto forwarding feature 
simply type: 


EMAIL OFF 


Messages can be sent by packet users to the internet users via the gateway. 
This applies to users at N6QMY as well as users at other bbs's. Begin by 
sending a message to IPGATE@N6QMY with the first line of the message being 
the letters "To:" followed by the internet address of the recipient. 


KB6UCZ de N6QMY > 
sp ipgate@néqmy 
Enter your subject: 
Meeting? 
Enter your message body: 
To: bob@hal.com 
Are you planning to attend the club meeting on Thursday? Give me 
a call. 73, Theresa 
AZ 


NOTE: That the recipient cannot respond to the message unless they 
are a ham and registered with the gateway. He/she becomes registered by 
sending a message from his internet host to gateway-request@lbc.com. 


REMOTE USERS: 

Remote users are those that do not log into N6QMY directly but merely 
appear from the packet world to use it as home. If a packet user checks 
the "White Pages" for a remote user the entry comes back as @N6QMY. 

The packet user then address his message to YOURCALL@N6QMY and the 

bbs will do the translation and forwarding to internet. 


It is not necessary for a person to know your actual internet address 
nox use the SP IPGATE method described above. From the packet network 
it appears that you are just another user at N6QMY. 


WHITE PAGES: 


The "White Pages" is a distributed database of all the bbs users. Most 
bbs users in the US are represented in the database as well as many from 


other countries. When a user chooses a home bbs, that bbs generates 

an update that is sent to the regional servers and then distributed to 
all the other bbs's. An entry consists of; call, home bbs, first name, 
zip, city and state. When a user wishes to send another packet user 

a message he/she consults the white pages (WP) for the home bbs. 


REGISTERING: 

Before a user, both local and remote, can send a message from internet 
into the bbs system he/she must register with the gateway. This is done 
by sending a message from the host that he/she intends to use to 
gateway-request@lbc.com with the following information: 


CALL: 
FIRST NAME: 
CITY & ST: 
ZIP: 


HOME BBS: 


When a request is received the "From" field is copied directly into 

a file with the requesters call. Whenever the gateway receives a message 
bound for packet it scans this file comparing on the "From" field. When a 
match is found the gateway uses the associated call from then on. If 
there is no match the mailer bounces the message with a one-liner 
indicating the the user must register. 


If you currently use another bbs as home this needs to be stated 
in the request. Otherwise you will be assigned N6QMY as your home. 
If you choose not to use N6QMY as your home you must make sure 
people know to send your message to YOURCALL@N6QMY to pass through 
the gate. Your WP entry will be wrong. 


EXECUTING BBS COMMANDS REMOTELY: 
Many of the commands available to local users is also available to 
remote users by sending a message to the bbs. Here is a subset of 
the commands currently available. 


LIST listing messages 

LOOKUP look up calls in the on-line callbook 

WHO call dump a users account information 

READ read messages and files 

USERS n display the last n users to connect to the bbs 
INFO display manual pages of various topics 


CD change directories in the file system 


LS/DIR display the contents of a directory 
WP call look a user up in the "White Pages" 
HELP get help on how to use a command 


Not all commands available to local users can be accessed via the 
gate. All interactive commands are disabled as well as commands 
that modify the users account. 


The command parser for the bbs is very powerful and the user can 
form very complex requests. For instance the following command 
is valid on the bbs: 


LIST LAST 20 BULLETINS FROM N6QMY 
LIST ALL BULLETINS ABOUT KENWOOD 


The ABOUT keyword is used to search the subjects of messages for a 
given pattern, in this case KENWOOD. It can appear anywhere in the 
subject line. 


This is an example of how complex all the commands can become. They 
can also be abbreviated down to the level understood my most other 
bbs programs. Any of the following will give the same results. 


L< N6ZFI 

LIST FROM N6ZFJ 
LIS < N6ZFJ 

L FR N6ZFJ 


In most cases a minimum number of unique characters is needed to 
distinguish a command. 


You can get a list of commands and a translation chart from the 
WORLI BBS command set to the NOARY BBS command set by typing 
the following commands: 


INFO COMMANDS 
INFO WORLI 


Other commands that you may wish to execute are: 


INFO MANUAL 
HELP HELP 
HELP LIST 


Now that you know what some of the commands are this is how you go 
about executing them. You send a message to cmd@bbs.lbc.com 
with your commands entered one per line or separated by semicolons. 


For example if you want to know if three of your buddies are in 
the white pages and if the bbs has any messages about the ICOM W2A. 


Send to: 
cmd@bbs.1lbc.com 


Subject: you can put anything here 
wp nOary n6zfj néune 
list all about w2a 


The bbs will execute the commands and respond to you via return mail. 


SENDING MAIL TO PACKET: 

Once registered the user is free to begin using the gateway to send 
messages from his host through the gateway into the packet world. 
How much you have to specify of a users address depends on how much 
the bbs already knows about the user. 


If the bbs knows the home bbs of the user and his home bbs is know to 
the N6QMY bbs, which many of them are, you simply need to supply 
the call of the user. 


n6éoim@bbs.1lbc.com 
If the N6QMY bbs doesn't know of the user but does know where his 
home bbs is, then you need to supply just the home bbs call in 
addition to the users. 

n6éoim%n6éiiu@bbs.1lbc.com 
Notice that the call and home bbs are separated by a percent sign '%' 
rather then the '@' which is used in the packet domain. This is because 
the '@' has a meaning in the internet address. 
If the N6QMY bbs has no knowledge of either the user or his home bbs, 
then you probably have the wrong home bbs or it is a new bbs. In which 
case you will have to supply the full address so the bbs will know 
how to route the message. 


n6oim%n6iiu.d#nocal.ca.usa.na@bbs.lbc.com 


This level of addressing is hardly ever needed and normally means that 
the home bbs is in error. 


Bulletins can be sent in a similar fashion. The address is made up 


of a keyword, which can be any six character word and a distribution. 
Distributions are local to an area. For instance SBAY is valid in 
northern CA, it probably has no meaning at all in Topeka, KS. 


Valid distributions are: 


ALLUS please avoid this one 
ALLUSW all western US 
ALLCA all California, any 2 letter state should work 


So if you trying to find a cw filter for a Kenwood TS440. 


Send to: 
want%allca@bbs.lbc.com 


Subject: Kenwood TS440, CW filter 

If you have one of these you are willing to part with please 
give me a call or leave message, thanks. 

73, KB6UCZ@N6QMY .#NOCAL.CA.USA.NA 


Be descriptive, brief, and always include your full return address in 
the message. Also please try to limit your distributions to small 
regions. Using the ALLUS distribution really slows down the flow of 
messages. 


INFO ON THE N6QMY BBS: 


The bbs came into being in April of 1993 and was the second one anywhere 

to run the NOARY BBS code (the first being NOARY himself). The bbs has 

4 rf ports, 1 phone port, the internet port, and is working on a voice synthesizer 
port. The latter would allow users to check for messages 

via DTMF from their handhelds. 


The bbs itself runs on a Sun workstation under Unix. The code was 

written by Bob Arasmith (NOARY) to focus on the user. Great care was 
taken to make the bbs very forgiving to the novice user but very flexible 
and powerful for the old-timer. The bbs can be configured to interact 
with each user differently. Some examples are: 


x List messages in either descending or ascending order. 


x Specify a list of keywords that the user wishes not to see displayed 
when a list is performed, similar to a kill file. 


* .Signature and .vacation files. 


*x Specify how many lines the users terminal is capable of displaying 


before scrolling, the bbs will feed info this many lines and pause 
allowing the user to catch up and continue or abort the operation. 
Similar to more. 


x Users can put commonly executed commands in keystroke macros that 
are accessible via a single keystroke. 


A manual is currently available describing the commands and their 
permutations. This manual will be available later this year as a 
postscript file. Run the command INFO MANUAL to learn how to get 
one via the post office. It is not available in an ascii format. 


If you have any questions about the internet gateway or the bbs 
in general please drop me a message. 


73, -pat 
néqmy@n6éqmy .4#nocal.ca.usa.na 
pat@lbc.com 


Date: 19 Apr 94 20:10:06 GMT 

From: agate!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu! 
ihnp4.ucsd.edu!pacbell.com!amdahl!amd!netcomsv!telesoft! garym@ucbvax.berkeley.edu 
Subject: Internet > Packet gateways?? 

To: ham-digital@ucsd.edu 


In <marcbgCoIC32.8x0@netcom.com> marcbg@netcom.com (Marc B. Grant) writes: 
>Does anyone have a list of Internet > Packet gateways? I use NOARY, but 
>would like to find others closer to some other geographic locations. 


Here is the short list of I have. It's probably not complete and some of 
the older ones may no longer be operating. I haven't verified any of these 
except NOARY which the one I use. 


Does anyone know of any we can add to the list? Especially any in 


Southern California? 
--GaryM 


Internet Email / Amateur Packet Gateways 


Location BBS Contact Address Date of Info 
Sunnyvale, CA NOARY gateway_info@arasmith.com 94-04 
Fremont, CA N6QMY gateway_info@lbc.com 94-02 
Arizona WB7TPY david@stat.com 93-05 


New Jersey KA2QHD johnd@ka2qhd.ocpt.ccur.com 92-05 


Pittsburg W2X0 durham@w2xo.pgh.pa.us 92-05 


Date: Tue, 19 Apr 1994 15:51:02 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.intercon.com!panix! 
zip.eecs.umich.edu! yeshua.marcam.com!news.kei.com!eff!blanket.mitre.org!world! 
dts@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <2ohiqh$q5n@hp-col.col.hp.com>, <2okn8t$c74@hpbab.mentorg.com>, 
<2om9kt$qtl@insos£1.infonet.net>ich.edu 
Subject : Re: NTS traffic on packet 


In article <2om9kt$qtl@insosf1.infonet.net> billh@ins.infonet.net writes: 

>In article <2okn8t$c74@hpbab.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) 
writes: 

>>In article <2ohiqh$q5n@hp-col.col.hp.com>, jms@col.hp.com (Mike Stansberry) 
writes: 

>>|> Hank Oredson (hanko@wv.mentorg.com) wrote: 

>>|> : In article <2oblv6$bme@hp-col.col.hp.com>, jms@col.hp.com (Mike Stansberry) 
writes: 


>>|> : |> Hank Oredson (hanko@wv.mentorg.com) wrote: 

>>|> : [> : In article <CnFLr1.Hu8@cbnewsh.cb.att.com>, ostroy@cbnewsh.cb.att.com 
(Dan Ostroy ) writes: 

>>|> : [> 

>>|> : |> : The days of handling traffic on 80M CW are pretty much gone now, just 
>>|> : |> AAKAAAKA 

>>|> : |> **k*k* WRONG!!! x** Just because YOU don't do it, don't assume it's 


>>|> : |> gone. I handle a LOT of traffic on 80M (and 40M) CW and so doa 
>>|> : |> lot of others! 


>>|> : [> 

>>|> : |> Mike, KOTER 

>>|> : [> 

>>|> 

>>|> : I'm certainly sorry to hear that. 
>>|> 


>>|> : Sounds terribly inefficient and error prone, when there are 
>>|> : better ways to do it. 

>>|> 

>>|> 1 -- 

>>|> 

>>|> : Hank Oredson @ Mentor Graphics 

>>|> : Internet : hank_oredson@mentorg.com 

>>|> : Amateur Radio: WORLI@WORLI.OR.USA.NOAM 

>>|> 

>>|> I guess you are just not interested in trying to help. Use your 
>>|> system or none at all, right? End of discussion. 


>> 

>>xx*x*x Flame mode on: 

>> 

>>So what should I do to try and help? Spell it out and stop whining. 

>> 

>>I guess differently than you do: I am trying to help by working to create 
>>a network that will gaurantee error free movement of messages 

>>anyplace in the world. 

>> 

>>Did I say "none at all"? No I did not. 

>>Please pay attention and read what was written (it's right up there ..). 
>>I said that 80M CW sounds terribly inefficient and error prone. 

>> 

>>Your response is what I hear from the majority of hams presently involved 


>>in NTS: "Oh my, Oh my, Run Away! - the Computers are coming, and we are 
>>afraid they will replace us!" 
>> 


>>In what way would you like me to help? By getting on 80M CW? 

>>No thanks, I've done that, and know perfectly well that it is error 
>>prone, slow, and can handle only a tiny amount of traffic. 

>> 

>>What I have been saying is that NTS fails to make use of all 
>>resources available to it, and in particular appears to be stuck in 
>>the dark ages of message handling. 

>> 

>>"End of discussion" sounds a lot like "I refuse to hear what you have 
>>to say, and will continue to refuse to hear it." 

>> 

>>xx*x Flame mode off: 

>> 

>> 

>>Indeed, not all NTS participants are like Mike. 

>> 

>>Some appear to understand what xcould*x be done, and would like to move 
>>NTS forward. However from my experience they are in the minority, and 
>>the "Mikes of the world" are in the majority. 

>> 

>> ... Hank 

>> 

>>-- 

>> 

>>Speaking only for myself (but you knew that, didn't you) 

>> 

>>Hank Oredson @ Mentor Graphics 

>>Internet : hank_oredson@mentorg.com 

>>Amateur Radio: WORLI@WORLI.OR.USA.NOAM 

>If CW/VOICE is so efficient, why does NTS highly suggest that msgs be limited 
>to 20 or 25 words or less. Compare that to length of many msgs/bulls on pkt. 


>bill Hays, WOOMV 


I guess you don't deliver much traffic. Some of us who do, prefer not to 
spend our whole lives at it. Remeber that there IS a human doing the delivery 
at the other end, and that NTS traffic is often send by and received by 
NON-hams. 


Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 
508-779-0439 Compusetrve: 74176 ,1347 


Date: Tue, 19 Apr 1994 15:57:38 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.intercon.com!panix! 
zip.eecs.umich.edu! yeshua.marcam.com!news.kei.com!eff!blanket.mitre.org!world! 
dts@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <2okn8t$c74@hpbab.mentorg.com>, <2om1ki$pkb@hp-col.col.hp.com>, 
<20ujlo$36a@hpbab.mentorg.com>um 
Subject : Re: NTS traffic on packet 


In article <2oujlo$36a@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: 
>In article <2om1ki$pkb@hp-col.col.hp.com>, jms@col.hp.com (Mike Stansberry) 
writes: 

> 

>|> Tell me what needs to be done to stop doubling, tripling, or even more 
>|> of messages. Tell me what needs to be done to get the time in transit 
>|> of messages sent via packet down from 5 to 10 days to something 

>|> reasonable. Don't tell me the above statements are not true. I'm 

>|> keeping track of the header information on the messages I deliver 

>|> that travelled by packet and the 5 to 10 days is the norm/. 

> 

>Ok, I'll tell you what to do to solve these problems. 

> 

>This is what we do in our part of the network whenever problems such 

>as you describe occur. Once located, the problem is usually quickly fixed. 
> 

>With respect to these 5-10 day delays you claim to see: 

> 

>1. Track the messages to find out where the delays occur. 

>2. Send this information to SYSOP@USA (or to the appropriate sysops 

> directly) so everyone involved knows where the problems occur, 

> and can work to fix them. 


>3. Create better routings so the delays do not occur. 


These are all excellent suggestions. The problem is, the folks who handle 
NTS traffic are not necessarily interested in the WAY that the tool (packet) 
works, just that it does work. I don't see anything wrong with that approach 
to packet at all. I, for one, do network stuff for a living, and like to do 
something OTHER than debugging networks when I get home. 


Perhaps the packet network systems should have some sort of routine test 
messages that get spread over the various paths and analyzed? There is no 
real reason to rely on end users to report problems of this sort. 


> 
>If the above is not clear, then simply post a few messages to SYSOP @ USA 
>including the headers from these delayed messages. We can't fix anything 
>until we know where the problem occurs. You have not given us that 
>information yet. 

> 

>With respect to the duplicates you claim to see: 

> 

>1. Track the messages to find out where the duplicates occur. 

>2. Send this information to SYSOP@USA (or to the appropriate sysops 


> directly) so everyone involved knows where the problems occur, 
> and can work to fix them. 

>3. Adjust your forwarding or connect parameters so the duplicates 
> no longer occur. 

> 


>If the above is not clear, then simply post a few messages to SYSOP @ USA 
>including the headers from these duplicated messages. We can't fix anything 
>until we know where the problem occurs. You have not given us that 
>information. 

> 

>The above is simply common sense: it is how we manage the network so it 
>will meet reasonable requirements on delay times, etc. 

> 

>Do we see delays and duplicates like this in the Pacific Nw? 

>Yes, of course we do. 

>Do we allow them to continue? 

>No, we do not. 

>We manage the network to locate and repair problems like this. 

>They are usually simple problems that yield to simple solutions. 


Now if the network were as well managed everywhere, we'd be all set. It 

takes people who WANT to spend their ham radio time doing this. I'm sure there 
are such people all over, but they are not necessarily the ones handling NTS 
traffic. 


> ... Hank 


> 

>-- 

> 

>Hank Oredson @ Mentor Graphics 
>Internet : hank_oredson@mentorg.com 


>Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 
508-779-0439 Compuserve: 74176 ,1347 


End of Ham-Digital Digest V94 #123 
KKKKKKKKKKKK KKK KKKKKKEKKRKEKR ARK A 


